<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
   
</head>
  <body>
       
<h1>Velocityme Starting Point</h1>
       
<h2>Contents</h2>
       
<ul>
      <li><a href="#Introduction">Introduction</a></li>
      <li><a href="#Motivation">Motivation</a></li>
      <li><a href="#Description">Description</a></li>
      <li><a href="#Use_Cases">Use Cases</a><br>
      </li>
       
</ul>
       
<h2><a name="Introduction"></a>Introduction</h2>
    This document is intended to define the starting point of the Velocityme
  project, i.e. the concept that was brought to group by Robert Crida.<br>
       
<h3>Background</h3>
    While working at Peralex, I was using a separate time sheet database
as  well as a software issue tracking program. The issue tracking allowed
people  to raise issues against a task under a project (tasks organized in
a tree).   The issues could have one of a number of states which was configurable
but   not at all constrained, i.e. any state could go to any other. In addition,
 the selection of states was generally only applicable to bug fixing and
not  other types of issues. A developer would be notified when an issue was
allocated   to him and could check the details on a web page. <br>
    <br>
    It is also possible to perform a search of the database to determine
which   issues are present according to various criteria. However, I felt
that it   was inadequate for project management as it was not possible to
refine a  search to only a part of a project therefore the results were usually
overwhelmed   with irrelevant issues. I discovered that the time sheet database
could also  operate using a similar tree of tasks but that it was in no way
linked to  the issue tracker and this appeared to present an opportunity
for improvement.<br>
       
<h2><a name="Motivation"></a>Motivation</h2>
    I felt that in addition to keeping track of bugs reported by a user that
  more functions could be performed including providing a mechanism for a
manager  to allocate work to developers, deal with issues other than bugs,
and integrate  the time sheet database into one mechanism. Ideally, all work
that people are doing should be driven by issues in the issue tracker and
all time spent working should be allocated to some issue in the task tree.<br>
    <br>
    A mechanism like this would provide a useful way for a company to implement
  project management with the aim of conforming to a quality system. It would
  allow for a variety of things to be achieved:<br>
       
<ul>
      <li>Resources (people) could be tasked by allocating issues to them 
in  a project task tree. This allows for a permanent record of the instructions, 
a history of action taken,  as well as a framework in which their time can 
be accounted for. They would  log time spent working on the issue thereby 
providing a useful time sheet.</li>
      <li>It should be possible to report a variety of different types of 
issues  (not just bugs) relating to among others project specification, design,
 implementation,  testing and follow-up.</li>
      <li>A manager would be able to investigate the relationships in projects
  between tasks and time and the resources and this would provide valuable
 information on the progress of a project as well as a providing data for
more accurately estimating the time that future projects may require (forecasting).</li>
       
</ul>
    Central to the whole system is the quality of the information in the
database.   I believe that if the tasks and issues are structured sensibly
and there  is a clear mapping to the actual work that people are doing then
there will  be reduced resistance to providing relatively accurate time information.
This will result in a database which contains an accurate and useful representation
  of the work that has been performed and how long it has taken to do it.<br>
       
<h3>Representation of data</h3>
    In order to make the best use of this, it must be possible to get useful
  representations of the data for analysis purposes (data mining). In all
cases,  the user will probably require that only a subset of the database
be shown and for this purpose, flexible search parameters must be available.
Once a search has been performed, data could be shown in the following ways:<br>
       
<ul>
      <li>The relationship between a person and a task. This would include
 the  time spent on it, the number and types of issues dealt with and possibly
 a comparison between the performance of different people/teams at resolving 
issues.</li>
      <li>The relationship between a task and a project. This could be used 
 to indicate if a task is taking an inordinately long time. This may indicate
  that it should be split into further tasks or perhaps have more resources
  allocated to dealing with it.</li>
      <li>The relationship between a person and a project. This could be
used   to determine how much time different people have spent working on
a project.</li>
      <li>By creating a task tree carefully, project milestones could be
included   as root nodes of branches. The state of the milestone could then
easily be  determined by checking the state of the corresponding task. If
there are outstanding issues then it is not complete and has not yet been
met.</li>
   <li>Warnings could be automatically generated when issues or tasks are 
not resolved by their due dates if one is specified.<br>
   </li>
       
</ul>
       
<h3>Generating statistics</h3>
    In addition to just viewing the information in reports and graphs, it 
would  also be useful for the system to be able to calculate statistics and 
perform  forecasting. Various options are described below:<br>
       
<ul>
      <li>The rate of issue reporting for a particular task could be used 
to  provide some indication of the state of the task. This option needs to 
be  investigated further but it is possible that from a graph of the issue 
reporting  frequency that a standard curve could be fitted to give an estimate 
of time to completion (at least to some probability).</li>
      <li>Summaries of outstanding issues for a task branch could be created
  which include information like how many have been issued, how many are
in   progress, how many have been resolved, what is the rate at which they
are   being resolved, etc.</li>
      <li>Gather information on utilization of resources. For instance one
 could  determine if particular individuals are handling the bulk of the
issues  or  taking much longer than other people to do a similar amount of
work.</li>
       
</ul>
       
<h2><a name="Description"></a>Description</h2>
       
<h3>Database Information</h3>
 The following sections describe the different types of information that
could be stored in the database.<br>
       
<h4>Users</h4>
    Each person who uses the system will have a user identity allocated to
 them  with a profile. In addition to individual users, the system will be 
able to  represent groups or teams of users.<br>
       
<h4>Tasks</h4>
    A task is going to be equivalent to some heading describing a component 
 of a project that needs to be completed. This could include various stages 
 of a project such as feasibility study, specification, design, implementation,
  testing and follow-up. It could also represent a milestone or target within
  a project. A task can belong to one project only and will be stored in
a  tree. Each task can have a maximum of one parent task but many have any
number  of child tasks. Thus, a milestone task would contain all the tasks
which needed to be completed to achieve the milestone.<br>
    <br>
    Tasks are intended to be completely generic and can have any name or
meaning   as long as it is sensible within the tree structure. That is, the
system is not going to distinguish between different types of tasks based
on anything other than their parameters such as priority and due date etc.<br>
       
<h4>Projects</h4>
    A project is effectively a tree of tasks that need to be performed before
  a project can be determined to be completed. Note that projects could be
 stored simply as a single task within the database or perhaps have a separate
 type (which could contain a number of tasks) so that extra information can
 be stored with it. It is probably better to go with the first option as
it  unifies the solution and reduces the number of different types of objects 
that need to be coded for and handled by user interfaces etc.<br>
       
<h4>Issues</h4>
    An issue is a description of an atom of work that needs to be performed.
  Issues will have to be allocated to a task (and additionally to a user
or  group). It should be possible to have a variable number of possible issue
 types which can be defined. An issue will at all times have some state.
The  state will be determined by the type of issues and the previous state.
If  a new type of issue is created then a state machine for that issue type
must  be specified. It will indicate all the legal states for the issue as
well  as the legal sequence in which they may be visited. Additional information
 could also be provided as to who would be responsible for the different
states  of an issue but this should probably be handled at a task level.
See the following figure for a example of a possible issue state machine
for a software bug.<br>
 
<div align="center"><a name="Issue_Bug"></a><img src="Issue%20Bug.gif"
 alt="Issue Bug" width="456" height="404">
 <br>
 </div>
    <br>
    Raising an issue of a particular type will result in it entering the
start   state for its type. An issue will be resolved once it has left the
state  machine, but it should be possible to re-enter the state machine again
if  the issue is raised again.<br>
    <br>
    An issue could be the responsibility of a list of users or a list of
groups.   Changing the state of an issue will typically result in a new user
being  responsible and that person being notified.<br>
    <br>
    Associated with an issue is a history of its state. Each state will have
  a description as well as a record of how much time was spent working on
it.  This provides the time sheet component of the system.<br>
       
<h3>Searching and representation</h3>
    Given the relational information described above, the following points
 can  be made about gathering information from the tree:<br>
       
<ul>
      <li>When searching a task for issues, it will recursively include issues
  in the child branches of the task. This implies that time spent on a task
  includes time spent in branch tasks.</li>
      <li>The database could be filtered by user to find time spent by a
user   on a task.</li>
      <li>It is possible to count the outstanding issues for a task (including
  branches).<br>
      </li>
       
</ul>
       
<h3>Security</h3>
    I would recommend that we take a Unix approach to security. Users will
 have  to log in to the system and their profile will have a user ID. Wherever
 security  or permissions are required they can be specified as for user,
group or global.  Permission for each of the types will then have to be in
a number of levels  such as read, write and execute. We need to determine
exactly what this will  mean in practice and how it can be used to restrict
visibility of different  parts of the database.<br>
    <br>
    For instance, if a project is just another task in a tree then a project
  specific user should only be able to see that project whereas a developer
  may be able to see a number of projects and a manager even more. Different
  users must also have different rights with regard to creating issues, creating
  tasks and modifying anything.<br>
    <br>
    Permissions should definitely be specified for each task but not necessarily
  for each issue. This can be used to restrict visibility. When searching
the  tree, a users permissions must be used to ensure that tasks that he
cannot  get access to are not included in the search.<br>
       
<h2><a name="Use_Cases"></a>Use Cases</h2>
       
<h3>Top Level</h3>
       
<div align="center"><img height="308" width="356" alt="Top level"
 src="Top%20Level.gif">
    <br>
       
<div align="left">    
<h3>Report Issues</h3>
    This use case is going to be used to report new issues into the database.<br>
    <br>
       
<div align="center"><img src="Report%20Issues.gif" alt="Report Issues"
 width="386" height="305">
 <br>
 
<div align="left"> 
<h4>Choose Type of Issue</h4>
   When a new issue is created, the user must specify what type of issue
it  is. Issue types can be created by the manager of the system and could
be project specific or could be generic, e.g. bug, resource availability,
specification  refinement. The issue will default to the start state of the
type that is  specified.<br>
     
<h4>Provide Description</h4>
   A description needs to be provided with a new issue.<br>
     
<h4>Set Parameters</h4>
   A new issue will have a number of parameters which may be set such as;
who  the responsible person is, when the issue is to be resolved by and what 
its  priority is, among other things.<br>
     
<h4>Choose Task for Issue</h4>
   A new issue must be created for a particular task. This will involve walking 
 the task tree to find the most relevant task. Because of the tree structure, 
 it is possible to move an issue up towards the root if it is not clear which 
 branch it should go into.<br>
       
<h3>Track Issues</h3>
       
<div align="center"><img src="Track%20Issues.gif" alt="Track Issues"
 width="410" height="360">
    <br>
    </div>
       
<h4>Notify Responsible Person/Team</h4>
   When a new issue is created, or an issue changes state, then the responsible 
 person should be notified that they have an issue to attend to it. This
could  be achieved using email.<br>
     
<h4>Provide follow-up Information</h4>
   In addition to changing the state of an issue it may be necessary to post 
 more information concerning its current state. This can be done using a follow-up
 and does not change the state or responsible person for the issue. Note
that  it may not necessarily be the responsible person who posts the follow-up.<br>
     
<h4>Change Issue State</h4>
   When the responsible person feels that they have performed the work required 
 of them for a particular issue then they must change its state to the next 
 appropriate one. This must be constrained by the state machine for the type 
 of issue. When changing state, a description must be provided in much the
same was as when an issue is created.<br>
     
<h4>Record Time on Issue</h4>
   Whenever an issue changes state or a follow-up is posted then the user 
must  report the time spent working on that particular issue. It will be recorded
 against that state of the issue for information purposes.<br>
     
<h4>Reassign Responsibility</h4>
   If the responsible person is inappropriate or overloaded it may be necessary 
 to change it to another. Probably a task to be performed by a manager.<br>
     
<h4>Change Parameters</h4>
   An issue may change priority or due date as circumstances change. Note 
that  how different issue priorities are handled is not really discussed yet
although  search results should perhaps be sorted by priority under certain 
circumstances.<br>
       
<h3>Check Statistics</h3>
       
<div align="center"><img src="Check%20Statistics.gif"
 alt="Check Statistics" width="360" height="280">
    <br>
    </div>
       
<h4>Select a Task</h4>
   Browse the task tree to choose a task for gathering statistics on. Typically, 
 a search will return results from any node in that branch of the task tree 
 that matches the parameters.<br>
     
<h4>Specify Search Parameters</h4>
   This is used to focus a database search and can be based on responsible
 person, type of issue, state of issue, priority, due date etc.<br>
     
<h4>Generate Report</h4>
   Once a search has been performed it will return a number of issues. A
report  can be generated listing the issues and showing their history. This
is a useful format for discussion purposes and dissemination.<br>
     
<h4>Generate Graph</h4>
   Once a search has been performed it will return a number of issues. Different 
 graphs can be drawn showing various relationships in the data such ratios 
 between different tasks, relative times spent on tasks, relative times by 
 user etc.<br>
     
<h4>Perform Forecasting</h4>
   Some forecasting may be performed for a task to estimate its completion
 date based on its current statistics although it is possible that other
things  could also be achieved.<br>
       
<h3>Configure System</h3>
       
<div align="center"><img src="Configure%20System.gif"
 alt="Configure System" width="411" height="264">
    <br>
     
<div align="left">   
<h4>Create Project</h4>
   This will either involve creating a new project in the database or be
handled  exactly the same as creating a task (if a project is simply a task).<br>
     
<h4>Create Task</h4>
   Creating a task requires selecting a location in the task tree and then
 providing task information such as the name and details of which users will
 be responsible for dealing with what types and states of issues.<br>
     
<h4>Create Issue Types</h4>
   Some form of editor will be required for editing and creating new types
 of issues which must allow the user to visualize the state machine for the
 issue type. It should be possible to add new states and form connections
to show the legal transitions. See bug issue state machine <a
 href="#Issue_Bug">example</a> earlier in the document.<br>
     
<h4>Set Task Parameters</h4>
   There are going to be various parameters on a task that must be set such 
 as what the legal issue types are, who the responsible users are, what priority 
 it has, due dates and permissions.<br>
     
<hr width="100%" size="2">    
<table cellpadding="2" cellspacing="0" border="1" width="100%">
      <tbody>
        <tr>
          <th valign="top" bgcolor="#cccccc">Author<br>
          </th>
          <th valign="top" bgcolor="#cccccc">Date<br>
          </th>
        </tr>
        <tr>
          <td valign="top">Robert Crida<br>
          </td>
          <td valign="top">2002-08-10<br>
          </td>
        </tr>
               
  </tbody>    
</table>
    <br>
 </div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>
